An application program interface (API) for a network platform can be used by developers to build Web applications and services. One such API is the .NET™ platform created by Microsoft Corporation of Redmond, Wash., USA. The .NET™ platform is a software platform for Web services and Web applications implemented in a distributed computing environment. The .NET™ platform allows integration of a wide range of services that can be tailored to the needs of the user. As used herein, the phrase application program interface or API includes traditional interfaces that employ method or function calls, as well as remote calls (e.g., a proxy, stub relationship) and SOAP/XML invocations. The .NET™ platform uses a framework that includes a Common Language Runtime (CLR) and base class libraries. Additional information regarding the basics of the .NET™ Framework can be found in a number of introductory texts, such as Pratt, Introducing Microsoft .NET, Third Edition, Microsoft Press, 2003.
The CLR is the heart of the Microsoft .NET™ Framework and provides the execution environment for all .NET™ code. Thus, code that is built to make use of the CLR, and that runs within the CLR, is referred to as “managed code.” In one instance, managed code is code that is destined to run on a virtual computing platform. The virtual computing platform is a platform that ‘just in time’ compiles the code at runtime into the machine platform's assembly/machine code.
The CLR provides various functions and services required for program execution, including just-in-time (JIT) compilation, allocating and managing memory, enforcing type safety, exception handling, thread management and security. The CLR is loaded upon the first invocation of a .NET™ routine. Because managed code compiles to native code prior to execution, significant performance increases can be realized in some scenarios. Managed code uses Code Access Security (CAS) to prevent assemblies from performing certain operations.
When writing managed code, the deployment unit is called an assembly which is a collection of one or more files that are versioned and deployed as a unit. An assembly is the primary building block of a .NET™ Framework application. All managed types and resources are contained within an assembly and are marked either as accessible only within the assembly or as accessible from code in other assemblies.
An assembly can be packaged as a data link library (DLL) or executable (EXE) file. While an executable file can run on its own, a data link library file must be hosted in an existing application. One type of assembly can be in a shared managed library, where shared libraries are typically one specific DLL. Each such assembly in a shared managed library has one or more methods that can be called by other assemblies. For example, an assembly can call to a method in a managed shared library, where the method is for a service that is accessible on the Internet.
Within any host, or program that is hosting other managed code, access rights for calls between an assembly and a method in a library's assembly should be defined and limited via rules to prevent code from doing something that is wrong within an environment. For instance, certain code can use synchronization in a way that can cause deadlocks or an inconsistent state leading to decreased reliability and throughput. It would therefore be advantageous to provide a rule that prevents this code from synchronization to thereby avoid the consequence of decreased reliability and throughput. Another situation where a rule is desirable is in the prevention of a call from an assembly to a method that might destabilize the hosting environment. In this case, the calling assembly could be one that is provided by a developer entity that is likely to be noncompliant with sophisticated requirements of the managed environment. As such, the calling assembly might be managed code that, when executed, might render the managed code environment unreliable, or might destabilize a computing device running the hosting environment. Still another situation where a rule, or hosting rule, is desirable is to prevent an assembly from calling for access rights to a resource that is inappropriate for an application that is being hosted. For example, when a Database Management System (DBMS) is being hosted in a virtual machine environment on a server, it would be inappropriate in a server environment to permit a call from an assembly for a user interface resource.
A managed environment can typically be accommodated by different kinds of hosts, each of which may have different hosting requirements to minimize threats to robustness and reliability. It would be an advantage in the art to provide a way for a host to selectively disallow certain classes of resource access to hosted code, where the hosting requirements would not necessarily be based upon a security feature. While different kinds of hosts can have different types of hosting requirements, it would be problematic to provide a separate method to perform the same function for each different kind of host and/or for each different type of hosting requirement. Accordingly, it would be an advance in the art to provide techniques for a host to prevent a call to a certain method from a certain caller to perform a certain function that could destabilize the hosting environment, while allowing the call to the same method from a different and/or more highly trusted caller, where the techniques could use the same method for different types of call prevention and for different types of hosts.